home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d2 / popup.arc / POPUP.DOC < prev   
Text File  |  1988-05-28  |  10KB  |  212 lines
  1. The following is a summary of a talk given by Bob Bierman of Living
  2. Videotext. Bob is the chief programmer for READY, a memory-resident
  3. outline processor. The talk was given on 2/11/86 at the IBM Special
  4. Interest Group of te Software Entrepreneur's Forum in the San
  5. Francisco Bay Area. Bob described many of the techniques used to
  6. develop a "machine-friendly" memory-resident program. Any confusion
  7. in the following is due to the summarizer, and not based on any
  8. problem of Bob's.
  9.  
  10. READY takes several steps beyond those of earlier memory-resident
  11. programs (TSRs). Perhaps most importantly, it allows the bulk of the
  12. TSR to reside in expanded memory (LIM EMS). A single version of READY
  13. self-configures to use EMS or not depending on its presence in the
  14. system. When EMS is used, the kernel of the TSR in normal memory
  15. uses only 4K bytes. The rest of the code and data in expanded memory
  16. use about 175K bytes.
  17.  
  18. When the READY hot key is pressed, the first step is to determine
  19. whether it is safe to interrupt DOS or the application at that time.
  20. We will return to this important issue below. Assuming it is safe,
  21. READY remaps the EMS page window to access one section of the EMS
  22. code. Control is transferred to the EMS page window. Then a 16K page
  23. window is used to swap whatever is in the top 160K bytes of normal
  24. memory into EMS, while pulling the rest of READY's code and data
  25. into the normal memory formally owned by the swapped area. Control
  26. is then transferred into normal memory and READY executes from there.
  27.  
  28. The swapping process takes about 1 second on a PC, and negligible
  29. time on an AT. This swap time is apparently not bothersome to the
  30. users of READY, who are most happy to get their normal memory back.
  31.  
  32. The swap of READY's code is made into high memory of the PC to
  33. hopefully avoid overwriting other memory-resident programs at the
  34. lower end of memory. This would be disasterous since a hot-key
  35. interrupt for those other programs would jump into READY's code
  36. at some undetermined point. READY checks other interrupts at
  37. invocation to help avoid this possibility.
  38.  
  39. The choice of the full swap from EMS to normal memory was not
  40. made lightly, according to Bob. The full swap was the weakest of
  41. several possibilities considered, but it had the advantage of working
  42. on schedule. The swap approach is also the least likely to cause
  43. problems when other TSRs take advantage of EMS. Bob pointed
  44. out three additional difficulties with executing directly from
  45. expanded memory -- if the code and data are larger than the 64K
  46. window of EMS, the program needs to have a well defined overlay
  47. structure allowing 16K chunks to be pulled in and out of the EMS
  48. page window; the disk transfer area (DTA) used by the TSR cannot
  49. reside in the EMS page window when an EMS RAMdisk is in use; the
  50. stack of the TSR should not reside in EMS due to some stack
  51. swapping problems when EMS functions are called.
  52.  
  53. READY also breaks new ground in the way it deinstalls itself.
  54. Many TSRs will deinstall whenever the user asks for it. This
  55. may leave holes in DOS' memory allocation structure, leading
  56. to problems. READY will not deinstall itself until it senses
  57. that all memory above itself is free. When the user requests
  58. deinstallation, READY sets a flag and then awaits the
  59. appropriate time for deinstallation. EMS memory is freed up
  60. immediately after the request is made.
  61.  
  62. The trickiest portion of writing the TSR is determining when
  63. DOS or the application is interruptable. DOS provides no clean
  64. services to make this determination. Bob recommends checking
  65. several different monitors before allowing the "pop-up"
  66. to occur.
  67.  
  68. The first step in popping up is detecting the application's
  69. hot key. In READY, INT 9 is used because they also want to
  70. detect some of the keystrokes (like Ctrl-ArrowUp) that the BIOS
  71. doesn't report. When the hotkey is detected by INT 9, a flag
  72. inside READY is set, but READY is not activated.
  73.  
  74. DOS provides two hooks that should normally allow safe popups.
  75. INT 21 function 34 returns a pointer to the InDOS flag in ES:BX.
  76. If the byte pointed to is 0, DOS is not active and therefore any
  77. DOS call can be safely made. However, function 34 itself cannot
  78. be called at any time. This function does a stack switch before
  79. returning its result, and apparently due to an oversight of its
  80. programmer, it does the stack switch with interrupts enabled.
  81. This opens the possibility for function 34 to mess itself up
  82. if it is called at the wrong time.
  83.  
  84. Bob also noted that the InDOS flag is not simply a binary value.
  85. It represents a count of "recursions" into DOS.
  86.  
  87. DOS can also be interrupted at certain times even when the InDOS
  88. flag is not 0. While DOS is waiting for keyboard input, the InDOS
  89. flag is set to (usually) 1, but at the same time, DOS also
  90. continually calls INT 28. Apparently, INT 28 was created
  91. specifically to allow the DOS PRINT command to run in the
  92. background. In any case, if the TSR watches for INT 28 calls, it
  93. is safe to use any DOS function above 9 during the INT 28.
  94.  
  95. Other monitors must also be checked before invocation.
  96. Because many programs use the BIOS calls without going through
  97. DOS, it is necessary to check whether the BIOS disk calls (at
  98. least) are active. This is done simply by taking over the disk
  99. interrupt (INT 13), and setting a flag (within READY's data
  100. area) upon entry to the interrupt, and resetting it upon exit
  101. from the interrupt. Before popping up based on some other
  102. interrupt, READY checks its own "InINT13" flag to make sure that
  103. no disk access is in progress. READY follows the same scheme
  104. for several other interrupts.
  105.  
  106. Looking at the DOS memory map after installing READY, it becomes
  107. apparent that all of the following vectors are taken over by
  108. the program.
  109.  
  110.   8  Timer
  111.   9  Hardware Keyboard
  112.   10 Video
  113.   13 Diskette
  114.   16 BIOS Keyboard
  115.   20 Program Terminate
  116.   21 DOS
  117.   25 Absolute Disk Read
  118.   26 Absolute Disk Write
  119.   27 TSR
  120.   28 Background Process
  121.  
  122. In all likelihood 8, 13, 21, 25, 26, and 28 are taken over
  123. specifically to allow safe popups without disturbing the system.
  124. INT 16 is used by READY's "key transfer" scheme to pass
  125. keystrokes in to DOS or an application (like the cut and paste
  126. of SuperKey and SideKick). INT 9 is used to supply special keystrokes
  127. and to aid in the pop up process. INT 10 is used to keep
  128. track of the video mode of the system (READY turns off the hardware
  129. cursor and maintains its own flashing reverse video block).
  130. INT 20 and INT 27 are most likely used to aid in the
  131. deinstallation process.
  132.  
  133. This author's guess of the overall popup scheme is as follows:
  134.  
  135.   INT 9 is used to set a flag that the hotkey (Ctrl-Keypad 5) has
  136.   been pressed or released.
  137.  
  138.   On each timer tick, the hotkey flag is checked. If set, the
  139.   READY-maintained inINTxx flags are checked for safeness. If
  140.   the INT 21 flag is set or if another "dangerous" BIOS or DOS
  141.   interrupt is active, activation does not occur at the
  142.   timer tick.
  143.  
  144.   On each INT 28 call, the hotkey flag is checked. If set,
  145.   DOS function 34 is also checked to be not greater than 1.
  146.  
  147. Without actually implementing this, it is a bit hazy but
  148. hopefully gets the idea across.
  149.  
  150. Bob emphasized that while "deinvoking" the popup it is just as
  151. critical that the safeness flags be monitored as while invoking it.
  152.  
  153. READY keeps no files opened between invocations. Files are
  154. opened only when an outline is read or written from memory, and
  155. then immediately closed. If all DOS handles are in use, READY
  156. will not be able to access the disk.
  157.  
  158. READY fully chains all interrupts that it takes over. This means
  159. that all interrupt handlers installed before and after it get
  160. their chance at the interrupt. Bob recommended that for chaining
  161. INT 16, the chaining process use the INT instruction rather than
  162. a CALL FAR instruction. By using INT rather than CALL FAR, handlers
  163. installed AFTER READY get another chance at the interrupt. This
  164. obviously requires that some flags be set inside READY to avoid
  165. an infinite recursion, and it is not necessary for most of the
  166. interrupts. It is particularly important, however, for INT 16
  167. (keyboard), where macro processors may need to be invoked. It
  168. also plays a role in the delaying mechanisms used when passing
  169. keystrokes into other applications.
  170.  
  171. READY does not take any special pains to work with programs
  172. (such as XYwrite) which take over the keyboard without chaining.
  173. Bob believes that any tricks to make these work will cause more
  174. problems than they solve. In particular, the SideKick trick
  175. of "stealing back" the hardware keyboard interrupt on each
  176. timer tick would be a disaster if other programs attempted
  177. to do the same thing. Living Videotext is working with other
  178. publishers to get their programs cleaned up and compatible
  179. in this sense. They are also trying to set a standard for the
  180. scan codes returned for keystrokes not supported by the BIOS.
  181.  
  182. A few general pointers: according to Bob, the "memory-resident
  183. interface code" of READY amounts to 12,000 lines of assembly
  184. language. Writing a bulletproof and machine friendly TSR is
  185. obviously no job for the weekend hacker! The rest of READY is
  186. written in Pascal (probably Microsoft, but definitely a linked
  187. version of Pascal). READY includes its own "relocator" which
  188. fixes up the EXE image of the program when it is relocated
  189. from EMS to normal memory.
  190.  
  191. The resident portion of READY could not have been developed
  192. on schedule without the ATRON hardware debugger, said Bob.
  193. This $1500 piece of hardware allows you to continue from
  194. hard crashes, and to investigate the state of the machine
  195. to determine what happened. If you can't afford this, at least
  196. get an NMI reset card. The "AT Technical Reference - Options
  197. and Adapters" is an invaluable guide that many developers
  198. do not have.
  199.  
  200. The PC Network is a disaster for memory-resident programs.
  201. It takes over interrupts in a very unfriendly way, and
  202. READY will not work with it.
  203.  
  204. A number of the major vendors of TSRs are currently meeting
  205. informally to reach some agreement on behavioral standards
  206. for TSRs. Watch for some announcements this year. Microsoft
  207. is decidedly against TSRs, and as versions of DOS roll by,
  208. support for TSRs (such as it is) will wane while support
  209. for true multitasking will improve.
  210.  
  211. summarized by Kim Kokkonen
  212.